Getting TEKnical by unknow

Author:unknow
Language: eng
Format: epub
Publisher: php[architect]
Published: 2023-04-15T00:00:00+00:00

11. Logs

“Treat logs as event streams”

From the perspective of a 12 Factor Application, all logs should be directed to stdout (although, as a personal hot take, applications should be directing their output to the most appropriate standard stream). stdout is one of the standard streams that POSIX environments define as writeable file descriptors. These streams provide input and output paths for a program and its operating environment.

The reason for logging into a standard stream instead of something like a log file is to allow flexibility in the running environment. For development, having your PHP application log to stdout or stderr makes it much easier to launch the dev server and just watch the logs as the application runs. All the logging goes to the terminal that the developer is watching.

In a production environment, these streams can easily be redirected by the environment. For many hosting solutions, the stdout/stderr output is pushed up to the web server, and the web server decides what to do. In other cases, PHP is directed to log all of that output to its own separate file.

The key is that the application itself is as accommodating as possible with logging and does not define the ultimate location or process for logging—it simply outputs to a known, accepted interface that works with almost anything.

For PHP applications, this can be accomplished in a few ways. The quickest and easiest way is to start adding calls to error_log() in the appropriate places in your application. This function, by default, writes to whatever PHP has been configured to be as the error log. This can be stdout, stderr, a file, or whatever. The function lets the PHP engine handle it all.

This is appropriate yet somewhat heavy-handed in that either you, as the developer, need to manually add in checks to see if something should be logged (like has the user configured debug-level logging, or just warnings), or you end up logging everything. While disk space is a cheap commodity today, a developer’s time is not. Reading through millions of lines of logs can be exhausting, even with automated tools.

A better option is implementing a PSR-3 compatible logger. 99% of the time, this means implementing monolog/monolog, PHP’s most widely used logging system. Monolog allows a developer to log messages at different pre-defined levels, like debug, info, error, or emergency. Then, the user can decide what levels they would like to see logged.

While Monolog can take a variety of different logging methods, if we take 12 Factor Application design into account, we would want to log to php://stdout. If you want to take proper Unix design patterns, you would want to log to php://stderr instead. Either case will work.

Why do I keep saying to use stderr instead of stdout for logging? The way the standard streams are designed, stdout is meant for application output, meaning the result of the program. If you are writing a script that calculates the number of words in a document, you would output the result, say 3000, to stdout.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.